Method for optimising the distribution of a service from a source to a plurality of clients in a network

ABSTRACT

This method for determining locations of service instances for optimising distribution of a service in a network, from a source to a plurality of clients each having predetermined requirements, wherein the network can be modelled by means of a graph, comprises steps of: placing a service instance in each leaf in the graph; and, starting from the leaves, for each service instance: checking whether the service instance when placed in a vertex on the next higher level can fulfil the requirements of all clients to be served by said service instance; and moving or not the service instance one level higher, depending on the result of the checking step.  
     Application to Point-To-Multipoint (PTM) service distribution in telecommunications networks of the WAN (Wide Area Network) type.

[0001] The present invention relates to a method for optimising thedistribution of service instances for providing a service from a sourceto a plurality of clients in a network. A service instance is an entitythat can provide a service to a client. In the case of Internetservices, the service instance is for example a proxy server; in thecase of information services, the service instance is for example adatabase; in the case of logistics, the service instance can be atransfer station. In a telecommunications network, the “clients” may befor example access networks or access nodes or user terminals.

[0002] The invention is described here, by way of non-limiting example,in its application to a telecommunications network of the WAN (Wide AreaNetwork) type, for Point-To-Multipoint (PTM) service distribution.However, it can be applied in a number of other domains, such aslogistics, traffic management, etc.

[0003] Depending on the topology of the network, the placing of serviceinstances may be rather complex.

[0004] In a distributed system wherein services are accessedsimultaneously by multiple, geographically distributed clients, anoptimal service distribution strategy should consider many factors,depending on the requirements of a variety of terminals andsub-networks. It should also consider the service requirements. Inaddition, an optimal strategy should limit the number of serviceinstances (i.e. equipment or service items providing the service to theclients), while providing adequate service quality to all clients.However, there is currently no well-defined solution for such PTMscenarios.

[0005] The present invention aims at overcoming this drawback.

[0006] To this end, the present invention provides a method fordetermining locations of service instances for optimising distributionof a service in a network, from a source to a plurality of clients eachhaving predetermined requirements, wherein the network can be modelledby means of a graph, the method being remarkable in that it comprisessteps of:

[0007] placing a service instance in each leaf in the graph; andstarting from the leaves, for each service instance:

[0008] checking whether the service instance when placed in a vertex onthe next higher level can fulfil the requirements of all clients to beserved by this service instance; and

[0009] moving or not this service instance one level higher, dependingon the result of the checking step.

[0010] According to a particular feature, the method further comprisesthe steps of determining that at least two service instances meet in theabove-mentioned vertex and combining these service instances.

[0011] Thus, thanks to the present invention, the minimum number ofservice instances necessary to provide the service to the clients in anetwork as well as the corresponding locations of these serviceinstances can be determined.

[0012] According to a particular feature, the method further comprises astep, prior to the placing step, of determining levels in the graph.

[0013] Thus, if the graph modelling the network does not comprise levelsper se, this step makes it possible to build a levelled structure of thegraph.

[0014] The checking step may comprise a table-based analysis step, or aPetri net analysis step.

[0015] With the same object as that mentioned above, the presentinvention also provides a vertex in a graph modelling a network,remarkable in that it implements a method as succinctly described above.

[0016] With the same object as that mentioned above, the presentinvention also provides a server in a telecommunications network,remarkable in that it is a source implementing a method as succinctlydescribed above.

[0017] With the same object as that mentioned above, the presentinvention also provides a device for determining locations of serviceinstances for optimising distribution of a service in a network, from asource to a plurality of clients each having predetermined requirements,wherein the network can be modelled by means of a graph, this devicebeing remarkable in that it comprises:

[0018] a lodging unit, for hosting a service instance;

[0019] a checking unit, for checking whether the service instance whenplaced in a vertex on the next higher level can fulfil the requirementsof all clients to be served by this service instance;

[0020] a processing unit, for coordinating the lodging unit and thechecking unit and for controlling the vertex; and

[0021] an input/output unit, for sending and receiving messages andservice instances.

[0022] According to a particular feature, the device further comprises acombining unit, for determining that at least two service instances meetin the vertex and for combining these service instances.

[0023] With the same object as that mentioned above, the presentinvention also provides a vertex in a graph modelling a network,remarkable in that it comprises a device as succinctly described above.

[0024] The advantages of the vertices, of the server and of the deviceare similar to those of the method according to the present inventionand are therefore not repeated here.

[0025] Other features and advantages of the present invention willappear upon reading the following detailed description of preferredembodiments, given by way of non-limiting examples.

[0026] The description refers to the accompanying drawings, in which:

[0027]FIG. 1 illustrates schematically a network wherein twointersecting sets of sub-networks for providing a service respectivelyfrom a server to two clients are identified, wherein the sets ofsub-networks contain those sub-networks that can provide the servicewith adequate service quality;

[0028]FIG. 2 illustrates schematically the complexity of the servicedistribution topology in the case of a higher number of clients;

[0029]FIG. 3 shows an example of a service distribution tree;

[0030]FIGS. 4a, 4 b, 4 c, 4 d are flow diagrams showing successive stepsof an optimisation method in accordance with the present invention, invarious embodiments wherein the network is modelled by means of atree-based topology;

[0031]FIG. 5 is a flow diagram showing successive steps of anoptimisation method in accordance with the present invention, in anotherembodiment wherein the network is modelled by means of a meshedtopology;

[0032]FIG. 6 is a non-limiting example of a table illustrating theanalysis carried out for a vertex in the graph modelling the network, inthe course of the optimisation method according to the invention in aparticular embodiment; and

[0033]FIG. 7 illustrates schematically a device according to the presentinvention, in a particular embodiment.

[0034] In the following, there is considered a telecommunicationsnetwork of the WAN type.

[0035] A service is to be distributed from a source, such as a server,to a plurality of clients in the network.

[0036] Before applying the optimisation method according to theinvention, a number of preconditions to be fulfilled may optionally bedefined. By way of non-limiting example, it may be required that themaximum number of service instances does not exceed a predeterminedpercentage (e.g. 25%) of the actual number of clients that are beingserved. Moreover, it may be required that the delay associated with thedistribution of the service to each client does not exceed apredetermined value (e.g. 500 ns, or any other value specified by theservice).

[0037] It is assumed that the network can be modelled by means of agraph, for example by using a tree-based topology (in which case thegraph is a tree) or a partially or fully meshed topology, both wellknown from a person skilled in the art.

[0038] The “destination points” in the graph are the sub-networks thatare connected to the clients (i.e. the leaves in the tree). Thedestination points know, for example from conventional routingprotocols, such as BGP (Border Gateway Protocol), the distance to theserver that initially provides the service.

[0039] According to the present invention, the maximum distance allowedbetween the service instances and the destination points is determinedon the basis of predefined metrics.

[0040] “Network metric” has the meaning of a function d(X,Y) defined onthe Cartesian square of a given set, e.g. a set of network nodes,satisfying a number of standard properties: d is non-negative, itsatisfies a triangle property, d(X,Z)≦d(X,Y)+d(X,Z), and d(X,X)=0 forany nodes X, Y, Z. To define a metric in a network, it is sufficient todefine the length of each connection between two nodes in the network.Given a number of metrics d₁, d₂, . . . , d_(k) defining the distancesbetween arbitrary nodes X, Y in the network, it is possible to reducethese metrics into a single, combined metric d(X,Y) by using existingprocedures well known from a person skilled in the art, for example bytaking the maximum of d₁, d₂, . . . , d_(k) or their sum or even theirconvolution with a given weight, depending on the subscriber or customerrequirements, the costs, etc.

[0041] A typical example of metrics is related to the quality ofservice, such as bandwidth, delay, jitter, reliability, security,response time RTT (Round Trip Time) or a combination of these factors.The required metric or a corresponding required minimum and/or maximumvalue is determined by the destination points (e.g. the clients in caseof service provisioning), the source (e.g. a service), the networkprovider, the service provider or any combination of these entities.

[0042] Therefore, depending on the context, the term “metric” may haveeither the meaning of a representation of a certain network, of aconnection or a link, or the meaning of a representation of distance ingraph theory, or more generally in metric spaces theory.

[0043] A destination point in the graph may represent either a singleentity, such as a client terminal or an access network, or a collectionof entities, such as all clients in an access network, all clients in aspecific area, all clients with the same characteristics, all customersof a specific logistics service, etc. It is to be noted that the clientsmay be connected to the destination points in an indirect manner, e.g.via a sub-network that is not modelled in the graph.

[0044] As shown in FIG. 1, several networks or sub-networks (sevenintersecting networks in FIG. 1) between the server and client(s) may beused to host service instances. The (sub-)networks, depicted by labelsSi, i=1, . . . , 32 on the drawing, are not necessarily on a single pathbetween the server and the client(s).

[0045] In the case of a single client, it is possible to determine allsurrounding (sub-)networks where a service instance would enableadequate service quality provisioning, i.e. would fulfil the client'srequirements. Such an analysis can be based on distance vector routingprotocols that use a table with the shortest paths to all destinations,i.e. (sub-)networks. The result of such an analysis step would be atable per client (or per access network) indicating all the(sub-)networks that can host service instances and provide adequateservice quality. This table can then be sorted on path distance from theclient(s) to the corresponding (sub-)networks, where each (sub-)networkis represented only once in the table (per client). The path distance isdetermined by any of the metrics or metrics combinations mentionedabove.

[0046] However, in a partially or fully meshed topology, many pathsgenerally exist between the client(s) and server and hence, theabove-mentioned tables will contain many (sub-)networks. Therefore, inthe case of a multiclient service distribution situation, anoptimisation step is required in order to determine, out of the possible(sub-)networks per client, the (sub-)networks for service distributionwith the minimum number of service instances. FIG. 1 shows that for bothclients C1 and C2, the sets of (sub-)networks that provide adequateservice quality have been identified. The (sub-)networks S10, S13, S14,S21, S28 and S29 are part of the intersection between the two networksand can carry out service provisioning for both clients. Although it ispossible in this scenario to identify an optimal (sub-)network from theintersection, the problem becomes complex when several thousands ofclients are involved and that an optimal service distribution must bedetermined for many intersections of many clients, such as in the caseof a plurality of intersecting sets of (sub-)networks, as illustrated inFIG. 2. Furthermore, adding or removing clients may affect a significantpart of the service distribution topology.

[0047] Therefore, a simplified topology representation is needed. Adelivery tree structure can be used in order to optimise the topologyand minimise the number of required service instances. Since the servicedistribution has a single source and multiple clients, the delivery treecan be created, by way of non-limiting example, by the Reverse PathMulticast (RPM) algorithm described by Hersent et al. in “IP Telephony:Packet-based multimedia communications systems”, Addison-Wesley, Harlow,2000.

[0048] As known from a person skilled in the art, the RPM algorithmbuilds source-based trees that span (sub-)networks with clients. Otherdelivery trees, such as minimum cost spanning trees or Steiner trees,can also be applied.

[0049] The RPM distribution tree algorithm creates a tree of(sub-)networks with exactly one shortest path from the server to allclients/access networks. Since there is a unique path from the server toeach access network, loops are impossible.

[0050] Each path from the server will end in one access network.

[0051] Thus, the access networks are leaves in the service distributiontree.

[0052]FIG. 3 shows an example of a service distribution tree. Such atree can be based e.g. on the RPM algorithm. The service network/theserver is the root of the tree and the access networks are its leaves.

[0053] Distributing a service from the service network to S6 restrictsthe service instances to be placed in one of the (sub-)networks on thepath S1, S2, S3, S4, S5, S6. Distributing a service from the servicenetwork to S21 implies that the service instances be placed in a(sub-)network on the path S1, S15, S16, S20, S21.

[0054] Different service requirements can be handled via a single treebuilt on the basis of a combination of metrics for these givenrequirements.

[0055] Different service distribution algorithms according to theinvention exist, depending on the topology of the network (tree-based ormeshed), the type of processing (central or distributed) and thetriggering mode, i.e. the mode of starting the analysis leading to theoptimisation.

[0056] The processing is either done in a central unit (e.g. the source,which is for example the location of the server), or distributed in thedifferent nodes (e.g. where the sub-networks are located).

[0057] The triggering, i.e. the start of the analyses in the centralunit or in the different nodes is either done by a central unit, levelby level, or is node-implicit, i.e. the different nodes perform anindependent processing and merely trigger the next node (which, as willbe seen later, is a higher level node) by sending a service instancethere.

[0058] Thus, there are at least four possible embodiments of theoptimisation method according to the invention:

[0059] a service distribution optimisation procedure with a tree-basedtopology, a distributed processing and a central triggering;

[0060] a service distribution optimisation procedure with a tree-basedtopology, a distributed processing and a node-implicit triggering;

[0061] a service distribution optimisation procedure with a tree-basedtopology, a central processing and a central triggering; and

[0062] a service distribution optimisation procedure with a meshedtopology, a central processing and a central triggering.

[0063] According to the invention, it is wished to minimise the numberof service instances. During the steps described below, the placement ofservice instances is semi-permanent, since, optionally, an additionalprocedure can be applied in order to try to move the service instancescloser to the clients without the need to replicating the serviceinstances. During this optional procedure, the service instances can beplaced in other nodes. Of course, this can only be done when the serviceinstance is moved towards the clients on a non-diverging path.

[0064] Depending on the chosen strategy, it may be decided to placeservice instances, not closer to the clients, but closer to the source.The invention applies of course to both cases.

[0065] For carrying out the procedure of moving the service instancescloser to the clients, there are two options:

[0066] either the last level at which two service instances have beenmerged is remembered for each service instance, and the service instanceis moved down, i.e. closer to the clients, until that level is reached;

[0067] or a node knows how many branches it has, and the serviceinstance is moved down as long as a node has only one branch leading tothe clients (i.e. until the service instance would have to be replicatedwhen moving down any further).

[0068] Let us first consider the case of a service distributionoptimisation procedure with a tree-based topology, a distributedprocessing and a central triggering. This embodiment is shown in FIG.4a.

[0069] First, a tree topology of the network is established, for exampleby using a conventional routing protocol (step 40 a). Either a singlemetric or metric combinations are used. In case of a metric combination,it can be advantageous to combine different metrics into a singleoverall metric, e.g. by means of weighing.

[0070] Next, service instances are placed in all leaves of the tree(step 42 a). For determining the leaves, either the source (or root) ofthe tree knows the leaves from the routing protocol information, or aservice instance is broadcast through the tree and the leaves are thosepoints that keep the service instance (instead of transmitting it).Service instances may be representatives of a real service instance(e.g. via a mobile agent, which is a software module), or the serviceinstance itself may be used. Leaves may have different distances to theroot, i.e. leaves may be located at different levels in the tree.

[0071] As an option (not shown), it is then checked whether there is aservice instance in a node before applying the trigger to that node.Otherwise, the trigger is sent to all nodes on the corresponding level(step 44 a), e.g. the trigger is broadcast and each node checks whetherit is on the requested level in the tree (e.g. each node increments alevel counter and broadcasts the message to all its child nodes). Theroot may also know the nodes for a given level from the routing protocolinformation.

[0072] If there is more than one service instance in the same node (test46 a), they are merged. This means that the service instances aretreated as a single service instance.

[0073] Thus, the new single service instance has to take into accountall requirements of all the clients that are now served by the newsingle service instance. This can be implemented for example byselecting the lowest or respectively highest value for each metric thatis requested by any of the clients. This merging procedure may becarried out at the end of the global loop, which is performed upontriggering of a given level. As a simpler variant, all requirements fromall clients are combined but not merged.

[0074] Next, the necessary information is fetched from the next higherlevel node, if any (step 50 a).

[0075] If, on the basis of this fetched information, i.e. consideringsimultaneously the characteristics of the next higher level node and theclient, service, etc., requirements, it is possible to move the serviceinstance to the next higher level node (test 52 a), then the serviceinstance is moved to the next higher level node (step 54 a). Otherwise,this means that the service instance cannot be moved higher and theservice instance is given a semi-permanent status (step 56 a). Thisinformation is transmitted to the root.

[0076] The global loop ends when all service instances have received asemi-permanent status (test 58 a).

[0077] Afterwards, optionally, as explained above, the procedure formoving the service instances closer to the clients (not shown) iscarried out.

[0078] If clients are removed or new clients are added, the procedure isreiterated for all nodes, unless nodes remember for which branches theyare responsible, which clients they serve and correspondingrestrictions.

[0079] Let us now describe a recursive variant of this procedure. Weassume that the leaves are aware of the requirements and restrictionsput on the service instance by clients that should be provided with theservice. This embodiment is illustrated by FIG. 4b.

[0080] The recursive procedure uses two messages, namely a requestmessage and a response message.

[0081] A node sends a request message to the adjacent nodes within thenext lower level in the tree (i.e. to its children nodes). If a leaf,that is a node directly connected to at least one client, is reached, aservice instance is created.

[0082] In a further embodiment of the invention, service instances areplaced at the leaves before the sending of a request message.

[0083] In both embodiments, a leaf performs the steps of:

[0084] 1. receive a request message

[0085] 2. check whether the service instance can be placed at the parentnode;

[0086] if so, a positive reply, comprising the requirements of the atleast one client, is sent;

[0087] if not, a negative reply is sent and the service instance isgiven a semi-permanent status.

[0088] It is to be noted that a request message can carry informationabout the characteristics of the parent node and the link needed forchecking whether or not a service instance can be moved into the nodefrom the level below.

[0089] The response message carries service instances and the relatedinformation, e.g. requirements on the service quality and otherrestrictions. A negative response may also be sent, meaning that noservice instance will be moved up from the child node.

[0090] As mentioned above, the tree topology is established and assumedto be known. For instance, based on routing protocol information, when agiven node receives a request message, it automatically deducestherefrom that the node that originated the request message is itsparent, and that the receiving node is a parent node for remainingadjacent nodes which are then considered to be its children nodes.

[0091] According to the recursive procedure, the following steps areperformed.

[0092] 1. In order to start the execution of the procedure, the serversends request messages to its children nodes (step 40 b).

[0093] 2. Each node waits for a request message from its parent node.

[0094] 3. When a request message is received from the parent node, thenode sends a request message to all its children (step 42 b).

[0095] 4. After the request messages are sent, the node waits forresponse messages from all its children.

[0096] 5. If all the response messages are negative (test 44 b), thenode sends a negative response to its parent upwards, and does not placeany service instance in it (step 46 b).

[0097] 6. Otherwise, if at least one positive response is received, thenode merges the service instances received from its children and buildsthe cumulative requirements and restrictions for the new serviceinstance obtained by merging (step 48 b). As a simpler variant, allrequirements from all clients are combined but not merged.

[0098] 7. Afterwards, the node checks whether the new service instancecan be moved upwards (test 50 b). If so, the node sends a positiveresponse with the service instance characteristics (step 52 b).Otherwise, a negative response is sent and a semi-permanent status isassigned to the service instance in the node (step 54 b).

[0099] 8. The execution of this procedure stops when the server receivesresponse messages from all its children nodes (test 56 b). In case of atleast one positive response message, a service instance with asemi-permanent status is placed in the server.

[0100] 9. Optionally, the service instances having a semi-permanentstatus can be moved closer to the clients, as mentioned above.

[0101] With slight modifications, this recursive procedure will work ina dynamic approach, when new clients are added or clients are deleted.For this purpose, each node shall keep its last response message and thelast response messages it received from its children. Then, upon arrivalof a response message, the node is able to re-evaluate thecharacteristics of the service instance and send a new response messageto its parent node if needed. Therefore, in a dynamic framework, nodesshould not wait until all the response messages are received from theirchildren. Each node should answer the message received from its parentafter a predetermined timer expires. The timer will have to be adjustedproperly in order to avoid too frequent re-evaluation of the serviceinstance in the node and too many new responses. It is to be noted thata timer may also be used in the procedure described above, carried outin a non-dynamic framework. The timer value can be determined from thepath distances, which information is available for example from therouting protocols.

[0102] Let us now consider the case of a service distributionoptimisation procedure with a tree-based topology, a distributedprocessing and a node-implicit triggering. This embodiment isillustrated by FIG. 4c.

[0103] Like in the previous cases, a tree topology of the network isfirst established and service instances are placed in all leaves of thetree (steps 40 c, 42 c).

[0104] A loop is then performed for each service instance. If there areother service instances in the node, they are merged (test 44 c, step 46c). As well as in the previous embodiments, as a simpler variant, allrequirements from all clients are combined but not merged. The necessaryinformation is then fetched from the next higher level node, if any(step 48 c). If it is possible to move the service instance to the nexthigher level node (test 50 c), the service instance is moved to the nexthigher level node (step 52 c) and optionally, a footprint, e.g. apointer, is left in the lower level node, indicating that the serviceinstance passed the corresponding node previously. If it is not possibleto move the service instance to the next higher level node, the serviceinstance is given a semi-permanent status (step 54 c).

[0105] Optionally, if there is a footprint in the node, a correspondingmessage is sent towards the root. A higher level node that receives thismessage (on its way to the root) checks whether it meets therequirements of clients that can be served by the sender of the message.If yes, it removes said requirements and calculates new cumulativerequirements for the remaining clients.

[0106] The loop stops when all service instances have been assigned asemi-permanent status (test 56 c).

[0107] Afterwards, optionally, the service instances having asemi-permanent status can be moved closer to the clients, as mentionedabove.

[0108] In this scenario, a node may know its level in the tree from therouting protocol information. This amounts to follow a level by levelapproach, as in the previous case (tree-based topology, distributedprocessing, central triggering) but without a central control andtriggering unit.

[0109] As mentioned above, instead of the corresponding service instancerequirements, each node can store a footprint corresponding to theservice instance when that service instance has passed this nodepreviously. When another service instance arrives in that node, it canretrieve all necessary information from the footprinted serviceinstance. A footprint may also be used to optimise the procedure: a nodeonly sends a message upwards (i.e. towards the root) when a newsemi-permanent service instance is to be placed in the node and thatnode has a footprint. When a higher level node removes the serviceinstance (because a lower level node has placed the service instance),all footprints between the higher level node and the node where theservice instance is now placed have to be removed. Additionally, thehigher level node informs the lower level node that hosts the serviceinstance for the clients served previously by the node, about theclients served and their requirements. Thus, each service instance isaware of the clients and their requirements on service instancecapabilities.

[0110] This procedure can also handle removals and additions of clientsdynamically. For the new clients, a service instance is placed in thecorresponding leaf node. The service instance is then moved towards theroot according to the procedure described previously. For removedclients, a message is sent upwards, faking that a service instance forthat client has been placed at a lower level. The higher level node withthe service instance that was serving this client then removes thecorresponding requirements for the removed client.

[0111] Let us now consider the case of a service distributionoptimisation procedure with a tree-based topology, a central processingand a central triggering.

[0112] This procedure is not shown in the drawings since it isessentially the same as the procedure that is carried out in the case ofa tree-based topology, a distributed processing and a central triggering(illustrated by FIG. 4a). The only difference is that no triggers areneeded. Further optimisations are possible, due to the fact that all therequired information is centrally available.

[0113] It is to be noted that a combination of central processing anddistributed information retrieval (wherein the root or server retrievesinformation by means of queries from the different nodes) would behandled by the same procedure.

[0114] The flow diagram of FIG. 4d summarises the succession of stepscarried out according to the optimisation method which is thesubject-matter of the invention, in a first preferred embodiment wherethe network is modelled by means of a tree-based topology.

[0115] Before the optional procedure (not shown), consisting of tryingto move the service instances closer to the clients, is carried out, theoptimisation method according to the invention is performed as shown inFIG. 4d.

[0116] During a first step 40, a service instance is placed in each leafof the tree.

[0117] Next, starting from the leaves in the tree (level N) and movingtowards the root (level 0), as shown by the initialisation step 41 andthe decrementation step 46, level by level in the tree, the followingprocedure is carried out:

[0118] For each vertex of the examined level where a service instance isplaced, it is checked (test 42) whether the service instance can bemoved further up towards the root of the tree, provided the root is notreached yet (a test 47 follows the decrementation step 46 and consistsin checking whether the index representing the level is equal to 0).

[0119] In order to know whether the service instance is allowed to bemoved higher up in the tree, the vertex can contact the next vertexhigher up in the tree, e.g. the corresponding resource manager in caseof a sub-network, in order to request the resource status. The requestcan be either a general request, or a dedicated request for thecorresponding relevant metrics.

[0120] As a variant, the vertex may use resource information receivedfrom higher levels in the tree without sending any request.

[0121] Thus, it is checked whether the service instance placed in thevertex fulfils the requirements of all clients.

[0122] If the result of test 42 is positive, the service instance ismoved to level i-1 (step 43). Otherwise, the location of the serviceinstance is left unchanged.

[0123] The two following steps 44 and 45 consist in considering thepossibility of combining several service instances with each other, andconsidering their possible cumulative or combined requirements,respectively. Step 45 is optional.

[0124] For example, during step 44, whenever two or more serviceinstances meet in the same vertex, they are advantageously combined intoone single service instance and the corresponding metric valuedescribing a requirement is either the minimum or the maximum value ofthe metric of the cumulative requirement, depending on the type ofmetric. For example, if the metric represents a delay, the single metricassociated with the cumulative requirement is the minimum of both formermetrics, whereas if the metric represents the bandwidth, the metricvalue associated with the cumulative requirement is the maximum of bothformer metrics. As a result of the combination of service instances, asingle combined service instance then provides the service to multipleclients simultaneously. As a simpler variant, all requirements from allclients are combined, but not merged.

[0125] During step 45, in case different metrics or combinations ofmetrics are used for the individual branches of the tree, they areadvantageously combined into a bigger set of metrics. For example, incase one of the branches of the graph uses only a metric based on delay,whereas another branch uses only a metric based on the bandwidth, thecombining vertex may use both the delay and the bandwidth for bothbranches or it may use each metric individually for each of thebranches. For example, for a video streaming service, the combination ofmetrics may include a predetermined maximum delay, a predeterminedminimum bandwidth and a predetermined minimum jitter (i.e. maximum delayvariation) to ensure an acceptable quality of service.

[0126] In another preferred embodiment, the network may be modelled, notby a tree-based topology, but by a meshed topology.

[0127] Let us consider the case of a service distribution optimisationprocedure with a meshed topology, a central processing and a centraltriggering. The procedure is as follows.

[0128] 1. A network metric is built based on given requirements andconstraints on delay, etc.

[0129] 2. A levelled structure of the network is built, so that thefirst level consists of the server, whereas other levels consist of thenodes being at the same distance from the server. Clients can be in anylevel, except the first one. The levels are ordered according to theirdistance from the server (the larger the distance, the higher the levelnumber).

[0130] 3. A set C of all clients that need to be provided with theservice is built.

[0131] 4. Each network node is marked as being able to serve a client incase the existing constraints allow the client to be served by a serviceinstance placed within that node of the network. Thus, one and the samenode can be marked with several potential clients.

[0132] 5. The level with the highest number, that is to say the levelmost distant from the server, is selected.

[0133] 6. A set S of so-called “forbidden” clients is built, which areclients that may be served by the given level but which cannot be servedby any service instances if placed closer to the server.

[0134] 7. If the set S is empty, the following step is step 11 below.

[0135] 8. The node N of the given level which may serve at least oneforbidden client and at the same time serve the maximal number ofclients is searched and a service instance with a semi-permanent statusis placed in that node.

[0136] 9. All clients that may be served by the node N are removed fromthe sets S and C (the removed clients are disregarded at further steps).

[0137] 10. If the set S is not empty, the following step is step 8.

[0138] 11. The procedure stops when the set C of clients is empty or alllevels have been considered.

[0139] 12. The level which is next to the level that has just beenconsidered and closer to the server node is selected, and the followingstep is step 6.

[0140] Step 8, which is a so-called “greedy” step, since it does notnecessarily deliver an optimal result, can be modified as appropriate,depending on the network and existing requirements. For example, it mayconsist in searching the node N of the given level which may serve themaximal number of forbidden clients and in placing a service instancethere.

[0141] The complexity of the proposed procedure may vary, depending oneffectiveness of implementation, and especially on data structures usedfor network representation. In order to increase efficiency,modifications of the procedure can be considered; for example, steps 2,3, 4 can be performed dynamically to the required extent at step 6.

[0142] Afterwards, optionally, the service instances having asemi-permanent status can be moved closer to the clients, as mentionedabove.

[0143] The flow diagram of FIG. 5 summarises the succession of stepscarried out according to the optimisation method which is thesubject-matter of the invention, in such a preferred embodiment.

[0144] As shown in FIG. 5, a preliminary step 50 consists of building acombined network metric based on given requirements and constraints onquality of service and other characteristics, that a service instanceshall fulfil.

[0145] A levelled structure of the network is built using the combinedmetric, pursuant to step 2 described previously. This may be done byusing a conventional routing protocol, which is aware of shortest pathstowards network nodes and their length.

[0146] The next steps 52, 53, 54, 55, 56, 57, 58 are similar to steps40, 41, 42, 43, 44, 46, 47, respectively, of the embodiment of FIG. 4dand their description is not repeated here.

[0147] In such a meshed topology, as well as in the case of a tree-basedtopology, the destination points in the graph are the sources where theservice instances start their way towards the service provider. Thedifferent destination points in the graph may be at different distancesfrom the service provider, i.e. the numbers of sub-networks between eachof the destination points and the service provider may be different.

[0148] Since the address of the service provider is known, the standardrouting tables of the routing protocol implemented in the network can beused to determine the next hop to reach the service provider.

[0149] Either the characteristics of all networks are available, e.g. ina table, or the characteristics of the next sub-network must be fetchedwhen it is known which sub-network is the next one on the way towardsthe service provider. The selection of the next sub-network is based onthe routing metric, which uses for instance delay as the routingcriterion. Since multiple metrics may have to be consideredsimultaneously, either for one client, or in the case of a cumulativemetric for multiple clients, the routing protocols have to be extendedto route data on the basis of multiple metrics simultaneously, unlessthe multiple metrics are combined into a single metric, as previouslydescribed.

[0150] For ensuring that different service instances be combined,service instances can leave an indication, which is called a“footprint”, in each of the sub-networks that they passed on their waytowards the service provider, so that these indications can be used byservice instances that arrive in the same sub-network during a lateranalysis step. It makes it possible to trace the corresponding serviceinstance and to combine several service instances.

[0151] The indication left in each sub-network in which the serviceinstance moved may be a pointer to that sub-network. In this case, whenmoving to a new sub-network, the service instance may possibly updateall pointers. However, pointers are either direct (i.e. they point tothe sub-network with the service instance) or indirect (i.e. they pointto a sub-network which is the next one on the way to the sub-networkwith the service instance). Only in the first case, all pointers have tobe updated. Therefore, no path traversal and checking is required ineach node, since the final address is known.

[0152] As a variant, in a sub-network in which the service instancemoves, it may leave, in addition to the pointer, all requiredinformation, such as the cumulative values of the metrics from the leafto that sub-network, as well as, optionally, the time at which theservice instance passes through the sub-network.

[0153] A variant for combining service instances can be based ondistance vector routing protocols that contain a table with the shortestpaths to all destinations. Multiple tables are required in order toreflect different metrics or combinations thereof, unless the multiplemetrics are combined into a single metric, as previously described.Exterior gateway routing protocols, such as the Border Gateway Protocol(BGP), contain such tables and are used for ensuring connectivitybetween sub-networks or autonomous systems. Thus, each sub-network knowsits distance to the root, i.e. the service provider.

[0154] The sub-networks then exchange information in order to determinewhich sub-network should move its service instance higher up in thetree. Similar mechanisms, such as the selection of a master, e.g. asapplied in many of the routing protocols or server selection proceduresin LANs, can be applied to determine the sub-network that can startmoving its service instance to the next higher sub-network. Taking intoaccount the metric-based distances, the resulting master can be the onethat is furthest away from the service origin entity.

[0155] The analysis implementation can be based either on a table asdepicted in FIG. 6, or on Petri nets, where the prerequisites are theconditions and the service instances are the tokens in the network.

[0156] The table of FIG. 6 may be stored in the vertex that is carryingout the analysis. It shows the ranges for the different clients C1 toC7. From the level in the tree (mentioned in the right-most column ofthe table) and the corresponding range for a specific client, thesub-network Si (i=1, . . . , 23) that is the closest to the root and canprovide adequate service quality to that specific client is known. Inthe shown example, the highest level in the tree is 1 (the root of thetree is sub-network S1) and the lowest level (the leaves of the tree) is6. For example, the sub-network S2 fulfils the requirements of clientsC1 and C2. It is to be noted that the prerequisites, i.e. theconditions, may reflect cumulative requirements.

[0157] The analysis starts by checking all level 6 sub-networks, todetermine whether the service instances placed at this level are allowedto be moved higher up in the tree. If yes, the service instancesconcerned are moved one level higher and a marking is inserted in thetable, for indicating that a service instance has reached that higherlevel sub-network.

[0158] In addition, the corresponding metrics are considered andpossibly combined with the metrics from other service instances, comingfrom other branches.

[0159] After all level 6 sub-networks have been checked, all level 5sub-networks are checked in an identical fashion, and so on.

[0160] Several parameters and additional indicators can optionally beincluded in the table above in order to refine or to speed up theanalysis. For example, as shown in the last row of the table, anindication may be given as to the number of intersecting sub-networksper client. Intermediate analysis results may be stored in the table tospeed up the process.

[0161] As a variant, instead of a table-based analysis, a Petri netanalysis can be used.

[0162] Petri nets are a graphical formalism for systems specification.They are formed from a finite set of places, a finite set of transitionsand a finite set of arrows connecting either places to transitions ortransitions to places. Graphically, places are usually represented bycircles and transitions by bars.

[0163] A Petri net is given a state by marking its places. A marking ofa Petri net consists of assigning a non-negative integer to each place.This is usually represented graphically by inserting a number of tokensin every place of the net.

[0164] A transition may have one or more input and output places. If anarrow goes from a place to a transition, the place is said to be one ofthe transition's output places. A transition is said to be enabled ifthere is at least one token in each of the input places. An enabledtransition may fire. This means that one token is removed from eachinput place and one token is inserted in each output place of thetransition. If more than one transition is enabled, the model isnon-deterministic, in the sense that given an initial marking, differentevolutions of the Petri net are possible.

[0165] In a Petri net, a transition usually models an event or action,and its firing represents the occurrence of the event or execution ofthe action. Thus, a transition is enabled if the conditions aresatisfied that allow the occurrence of the modelled event or action. Thepresence of a token in a place may denote the existence of somecondition. For instance, a place may model a resource, and the existenceof one or more tokens in that place means the availability of one ormore instances of that resource. For a more detailed description of thebasic principles of Petri nets, reference can usefully be made to“Fundamentals of Software Engineering”, by Ghezzi et al., Prentice HallInternational, New Jersey, 1991.

[0166] According to the invention, the distribution tree is modelled bya Petri net with the same shape. The sub-networks are the places, theservice instances are the tokens that carry the corresponding metricsvalues along and the transitions have associated conditions that arerelated to the maximum distance that the service instance is allowed tobe away from the clients, i.e. from the leaves. This distance can bebased on any of the corresponding metrics or combination of metrics thatis important for the clients. Each sub-network is reflected by a placein the Petri net. A service placement in a specific sub-network (i.e. avertex in the distribution tree or in the meshed topology) is modelledby a token in a place in the Petri net.

[0167] Tokens are first placed in the leaf places. Moving the serviceinstance towards the root is done by moving the tokens up through thePetri net. In order to move a token from one place to the next, atransition must be enabled and must fire. The firing of a transition isdone by the same algorithm as above. To this end, the token will havevalues that are used and updated by the analyses.

[0168] The merging of service instances is done by having transitionswith less output tokens than input tokens.

[0169] The final distribution of the service instances is reached whenthe Petri net stops to evolve, i.e. when the tokens do not move andmerge any more.

[0170] Petri nets can be applied to both the tree-based and meshedtopologies.

[0171] Scheduling policies can also be used. When the purenon-determinism of the Petri net model is not adequate, we face theproblem of specifying a policy for selecting a transition to fire amongall the enabled transitions. A fairly simple way to solve this problemis to attach priorities to transitions. Then the firing rule is modifiedas follows: if, in some state, several transitions are enabled, only theones with maximum priority are actually allowed to fire.

[0172] Priorities are usually defined statically. If tokens carry avalue, however, dynamic priorities may be defined, whose values dependon the values of the tokens of the input places of the transitions.

[0173] Timed Petri nets can be used as well. Timed Petri nets are Petrinets in which a pair (t_(min), t_(max)) is associated with eachtransition. Again, such values could be constant or computed asfunctions of the values of tokens at the input places. Once a transitionis enabled, it must wait for at least a time t_(min) to elapse before itcan fire. Also, if enabled, it must fire before a time t_(max) haselapsed, unless it is disabled by the firing of another transitionbefore t_(max). A timed Petri net is equivalent to an original Petri netif, for every transition, t_(min)=0 and t_(max)=indefinite.

[0174] As shown in FIG. 7, a device for determining locations of serviceinstances for optimising distribution of a service in a network, from asource to a plurality of clients each having predetermined requirements,wherein the network can be modelled by means of a graph, according tothe invention, comprises:

[0175] a lodging means 70, for hosting a service instance,

[0176] a checking unit 72, for checking whether the service instancewhen placed in a vertex on the next higher level can fulfil therequirements of all clients to be served by this service instance, asdescribed previously,

[0177] a processing unit 74, for coordinating the lodging unit 70 andthe checking unit 72 and for controlling the vertex, and

[0178] an input/output unit 76, for sending and receiving messages andservice instances.

[0179] In the particular embodiment illustrated in FIG. 7, the devicefurther comprises a combining unit 78, for determining that at least twoservice instances meet in the vertex and for combining these serviceinstances, as described previously.

1. A method for determining locations of service instances foroptimising distribution of a service in a network, from a source to aplurality of clients each having predetermined requirements, whereinsaid network can be modelled by means of a graph, said method comprisessteps of: placing a service instance in each leaf in said graph; andstarting from the leaves, for each service instance: checking whetherthe service instance when placed in a vertex on the next higher levelcan fulfil the requirements of all clients to be served by said serviceinstance; and moving said service instance one level higher, dependingon the result of the checking step.
 2. A method according to claim 1,further comprises the steps of determining that at least two serviceinstances meet in said vertex and combining said service instances intoone service instance.
 3. A method according to claim 1 further comprisesa step, prior to said placing step, of determining levels in said graph.4. A method according to claim 1, wherein said checking step comprises atable-based analysis step.
 5. A method according to claim 1, whereinsaid checking step comprises a Petri net analysis step. 6-7. (Cancelled)8. A device for determining locations of service instances foroptimising distribution of a service in a network, from a source to aplurality of clients each having predetermined requirements, whereinsaid network can be modelled by means of a graph, comprising: lodgingmeans, for hosting a service instance; checking means, for checkingwhether the service instance when placed in a vertex on the next higherlevel can fulfil the requirements of all clients to be served by saidservice instance; processing means, for coordinating said lodging meansand said checking means and for controlling said vertex; andinput/output means, for sending and receiving messages and serviceinstances.
 9. A device according to claim 8, further comprises combiningmeans, for determining that at least two service instances meet in saidvertex and for combining said service instances into one serviceinstance.
 10. (Cancelled)
 11. A system for determining locations ofservice instances for optimising distribution of a service in acommunication network, from a source to a plurality of clients eachhaving predetermined requirements, wherein said communication networkcan be modelled by means of a graph, comprising: means for placing aservice instance in each leaf in said graph; means for starting witheach leave and determining whether said service instance, when place ina vertex on the next higher level, can fulfill the requirements of allclients to be served by said services instances; means for moving saidservice instance one level higher in response to an affirmativedetermination.
 12. The system of claim 11 further comprises the meansfor determining that at least two service instances meet in said vertexand further combing said two service instances into one serviceinstance.
 13. The system of claim 11 further comprises the means fordetermining levels in said graph prior to placing said service instancein said each leaf in said graph.
 14. The system of claim 11 wherein saidmeans for determining further comprises a table-based analysis means.15. The system of claim 11 wherein said means for determining furthercomprises a Petri net analysis means.